Secure Open Computing Strategy For Global Enterprises A White Paper March, 1993 General Systems Division Table of Contents 1 Introduction 1.1 Hewlett Packard Commitment to Security 1.2 Purpose and Scope 1.3 Strategy Development Process 2 HP Information Security Vision 3 HP Information Security Value Proposition 4 HP Information Security Strategy and Development Model 4.1 Strategy Principles 4.2 HP Distributed Computing Environment (DCE) Security Strategy 4.2.1 Distributed Computing Environment (DCE) Overview 4.2.2 DCE Security Evolution 4.2.3 Longer-Term DCE Security Evolution 4.2.4 Security Aspects Not Addressed by DCE 4.2.5 Role of Local System Support within DCE Domains 4.2.6 DCE Security Policy Directions 4.3 DCE-Independent Methods to Enhance Computing Environment Security 4.3.1 Enhanced Security Operating System Mechanisms 4.3.2 Application Support Services 4.3.3 System Management Facilities 4.3.4 Networking Elements 4.3.5 Trusted Hardware Components 4.3.6 Alternative APIs for Security Services 4.3.7 Alternative Security Architecture Standards 4.4 Network Planning 5. Application of HP's Security Strategy: Case Example 1 Introduction 1.1 Hewlett Packard Commitment to Security Hewlett-Packard continues to establish itself as a strategic information technology supplier to industry leading enterprises worldwide. Increasingly, these large global accounts are adopting open systems on a global scale and new paradigms of computing such as client-server. These trends complicate the job of securing an organization's information assets from unauthorized access. On the leading edge of these trends are information-intensive market sectors such as financial services and telecommunications. Typically, organizations in these sectors require a security strategy that supports both the distributed cooperative application model of the future as well as the traditional monolithic application model prevalent today. HP is committed to delivering security solutions that address the complex security challenges associated with the need to evolve to future distributed computing environments. 1.2 Purpose and Scope The objectives of this document are two-fold. First, this document describes Hewlett-Packard's information security vision and development model for global, distributed, computing environments. HP calls this vision and model Secure Open Computing. Critical technology components of HP's model are identified and HP's position relative to technology alternatives are articulated. Second, this document establishes a framework by which customers can compare and contrast HP's vision, strategy, and technology assessments with that of their own. 1.3 Strategy Development Process HP's strategy development process began with the formation of a System Security Council to coordinate the development and implementation of the Secure Open Computing strategy company-wide. This team consists of marketeers and technologists representing multiple divisions across the company. HP's strategy is shaped by a number of inputs. HP is partnering with early adopters of security technology to gain a detailed understanding of customer needs and experience with implementing leading-edge security technologies. HP's strategy anticipates and integrates technology advances spawned from both internal research and industry innovation. Finally, HP closely monitors competitor and standardization activities to ensure market acceptance of its solutions. While HP's security vision will remain stable, its strategy for implementation may adjust in response to the pace of technological advances, standardization processes, or changes in customer needs. HP invites its leading accounts to comment on the strategy articulated in this document to ensure that it reflects their evolving needs. 2 HP Information Security Vision The goal of any product strategy is to progress a program towards a clear and stable vision. Thus, before elucidating on strategy, it is necessary to describe HP's vision of Secure Open Computing. In general, HP envisions computing solutions with security services that can be characterized as Comprehensive, Configurable, and Usable. At the same time, HP envisions a security architecture that is consistent with investment protection and business and information technology (IT) Strategic objectives. COMPREHENSIVE SECURITY The goal of HP's security solution is to offer a comprehensive set of security services that ensure the availability, integrity and confidentiality of an organization's global information assets. These information assets can span both legacy and distributed application resources, PC to mainframe class systems, as well as to customer and supplier system interfaces. Comprehensive security includes the concept of end-to-end (ETE) security of network message and transaction traffic. ETE security must be implemented such that there is minimal change in the network infrastructure and assurance that the introduction of a single, inherently non-secure component can not compromise the security of the whole network. Finally, comprehensive security encompasses not only system and software functionality and tools but training, consulting and support, disaster recovery services, and meaningful documentation. HP anticipates the need to integrate in-house development with security solutions from third-parties so that customers have a degree of choice and access to best-in-class solutions. Similarly, HP will work with other systems vendors to ensure interoperability and interface consistency where possible. CONFIGURABLE SECURITY Security building blocks must be modular and flexible to allow entities to tailor their security implementation to meet the requirements of their particular organization's security policy. All available security services (i.e., authentication, authorization, confidentiality, integrity, non-repudiation, audit) need the ability to be implemented independently or in any combination. USABLE SECURITY Unintentional user mistakes are responsible for as much as 90% of all security breaches. Most mistakes are caused by the complexity of security facilities and user-interfaces that users with no security and operating system expertise are expected to utilize. Therefore, within the constraints of an individual organization's security policy, security must be unobtrusive to the end-user and should enhance rather than degrade the productivity of end-users whenever possible. For example, smart cards will support a single sign-on capability for end-users to access all authorized resources of the network from anywhere on the network. Administrators require logically centralized management of security services that are consistent and integrated with a common system and network management framework. Developers require programming aids and tools for construction, test, and maintenance of secure applications. STRATEGIC SECURITY Organizations will evolve their computing infrastructure to more distributed or cooperative paradigms to achieve lower cost of operations, increased productivity and efficiency, or competitive advantage. HP's security must be complementary and not incongruous with these objectives. For example, with respect to competitive advantage, HP envisions a security perimeter that can be extended to include both customer and supplier system interfaces, thus removing the security obstacles inherent in entering or developing new markets such as home banking, EDI, enhanced telecommunications services, multi-media, and portable/mobile computing services. A model for visualizing several key elements of HP's Secure Open Computing vision is offered above. HP refers internally to this high-level model by the code name UT. The 'U' represents the secure end-to-end communication between users or processes over a global network. The 'T' represents the comprehensive family of security services which are administered by consistent network management interface. This graphic also introduces and defines some fundamental security terminology used throughout this document. 3 HP Information Security Value Proposition As HP pursues its vision of Secure Open Computing, HP will sustain four important advantages relative to its competition. First, HP will maintain industry leadership in driving and implementing international security standards. In general, HP is among the first to be compliant with new standards and HP technologies are routinely selected as industry standards. HP has over 300 employees participating in standards committees. Second, HP will provide integrated security solutions across the broadest range of scalable business servers and devices. The HP9000 family of workstations and business servers based on the HP Precision Architecture (RISC) -- widely regarded in the industry as the broadest scalable family of computing systems -- is suitable for everything from individuals to small work groups to large data center configurations. Third, HP will provide excellent pre- and post-sales security consulting, training and support. HP views consulting and support competency to be a critical success factor in its security solution. Over the past nine years of U.S. Datapro surveys, HP has consistently ranked the highest in support and service. Additional independent research rates HP as a worldwide leader in overall customer support satisfaction, as well as customer satisfaction. Finally, HP offers early access to cutting-edge business re-engineering building blocks including distributed security technology. HP is a primary architect and technology contributor to the Open Software Foundation's Distributed Computing Environment (DCE) and Distributed Management Environment (DME). HP also has significant experience in delivering multi-level secure system and network solutions to the most complex security environments within federal defense and intelligence communities worldwide. 4 HP Information Security Strategy and Development Model This section describes HP's Secure Open Computing strategy for global enterprises. It presents HP's strategy in the context of the model shown below. The figure illustrates a distributed security model which consists of four conceptual layers in which security can be implemented. 1. Distributed applications and applications which implement security policies 2. Distributed security middleware 3. Operating system security 4. System & network hardware security There are two general schemes to structure and implement security services and technology. One scheme is represented by the DCE framework as depicted on the right hand side of the figure. HP has chosen to adopt DCE as its strategic distributed computing and distributed security framework. HP believes that DCE provides the most comprehensive and flexible approach to providing security in a distributed environment. This choice, however does not imply the abandonment of or incompatibility with other security environments. However, HP does target DCE and DCE security solutions at customers which are willing to re-engineer parts of their IT business and make the paradigm shift to true client-server computing. As shown in the figure, the DCE security framework provides the distributed security middleware as well as some elements traditionally the domain of application policy and operating system security. The other scheme shown on the left essentially represents a piece by piece approach to addressing specific security threats. It consists of multiple, layered, overlapping solutions which can provide different aspects of security. For example, Kerberos provides a distributed framework for authentication with a fixed policy but no operating system security elements while RACF provides security at the operating system level with little regard for distributed environments. Similarly, hardware-based encryption devices increase security only at the network communications level. This approach is viable mainly in computing environments in which a few primary threats have been identified and the preservation of legacy systems and applications is a primary goal in addressing these threats. HP's leading edge customers are investing in both approaches. As a result, HP's strategy must address both schemes. Section 4.1 states the principals or philosophical pillars upon which HP's strategy for addressing either scheme rests. As a technology provider, HP provides the DCE distributed security framework which is the central technology framework of HP's strategy. This framework is described in Section 4.2. As a vendor of robust, secure systems and networks, HP provides a variety of operating system security, network security, and add-on security products which complement DCE or are of value in non-DCE environments. These features are described in Section 4.3. Finally, Section 4.4 details network planning issues which are relevant to all security conscious customers. 4.1 Strategy Principles HP's secure open computing strategy is based on three key principles or success factors. First, HP will leverage -- and not trade-off -- its traditional strengths in the areas of interoperability, usability, performance, and service & support. Second, HP is committed to providing application investment protection when migrating to enhanced security environments. For forward migration of new applications HP's intention is to adopt industry standard APIs. For co-existence of legacy applications with future distributed applications, HP's goal is to provide migration tools and/or application access transparency. Third, HP is committed to pro-actively submitting and implementing industry and international computing standards including information security-specific standards. To facilitate multi-vendor secure interoperability HP will work cooperatively with competitors by, for example, hosting interoperability forums or engaging in joint development activities. 4.2 HP Distributed Computing Environment (DCE) Security Strategy HP has identified DCE as a critical strategic framework for delivering future open distributed computing solutions. HP believes that DCE will set a de facto standard for secure distributed computing in a multi-vendor environment. As a result, HP is committed to providing DCE on both the HP-UX and MPE/ix operating system platforms. HP's strategy to provide Secure Open Computing is multi-faceted. First, HP will continue to be a leader in implementing and evolving the basic DCE security features described in the next section. The following sections 4.2.2 and 4.2.3 describe the near-term and longer-term strategy for enhancing DCE to provide increased service levels, extensibility to future and legacy systems, and additional facilities such as DCE auditing. Section 4.2.4 exposes HP's position on security services which currently remain outside the definition of DCE such as non-repudiation facilities. HP will invest in local system capabilities identified in section 4.2.5 which complement the level of security service provided by DCE such as encryption/integrity hardware for performance and smart card support for safe key distribution/storage and two-factor authentication. Section 4.2.6 describes future directions for integrating additional security policies into DCE. Finally, Section 4.3.7 describes a security architecture alternative to DCE. 4.2.1 Distributed Computing Environment (DCE) Overview The DCE security component is a set of services and facilities that provide distributed applications with a trustworthy mechanism for controlling access to application resources. The fundamental pieces of the security component are (1) a logically centralized registry of user information and privileges; (2) a common authorization model across disparate applications; (3) integral facilities for inter-domain administration and connectivity; (4) integral facilities for communication integrity and confidentiality; and (5) a hierarchical design of security services that provide high availability and robustness in the presence of partial system failures. The DCE user registry is an extension of the distributed name system that specializes in storing user security information. The logon sub-system of DCE accesses the repository and provides users with a single identity across all systems. Authentication of the user's identity is performed using the Kerberos Version 5 authentication protocol. Access to services in the DCE is controlled through the use of access control lists (ACLs). DCE ACLs are a superset of the draft POSIX ACL specification -- extending the basic functionality with provisions for multiple administrative domains and for use by services other than conventional file systems. This facility provides a common model for authorization across all basic DCE services as well as end-user developed applications. The protection of resources (e.g., files, database objects, etc.) via ACLs is only meaningful when the application exporting the resource can reliably determine the identity of the caller. The DCE remote procedure call (RPC) facility is integrally connected with the security component to provide mutual client/server authentication of identity. Applications can additionally request that data transmitted via the RPC be protected with either secure integrity or confidentiality protocols. Security is an essential service of the DCE and is therefore implemented in a robust, highly available manner. In a distributed environment, robustness is not simply a matter of careful coding. Partial failures due to network outages or scheduled maintenance are a part of normal operations. A robust distributed service is one that continues to operate, possibly with some limitations, in the presence of these failures. DCE uses a hierarchical and redundant approach to providing security services. The logically centralized security service is replicated so that network partitions do not prevent applications from obtaining necessary security information. Client machines retain enough data from the network service to allow them to provide local services to users in the event that the network is completely unavailable. 4.2.2 DCE Security Evolution The evolution of DCE falls into two broad categories. In the short term DCE is maturing though the completion and improvement of features present in the base design. In the longer term additional features are added to the environment to extend its suitability to broader application domains. HP's strategy calls for key efforts in both areas and HP is collaborating with others to define long-term extensions for DCE. Replication of the user registry database is the primary short term enhancement to the DCE security service. This facility is crucial to the creation of large distributed environments -- protecting the environment from the vagaries of partial failures. 4.2.3 Longer-Term DCE Security Evolution The OSF has solicited proposals in the form of requests for comments (RFCs) to help define the future of DCE. This process has been very successful, and has resulted in a number of contributions to the OSF by HP and others in the DCE community. HP's contributions are in the areas of Extensibility to Legacy Systems, Delegation, Inter-domain Access, and Stronger Authentication. Other vendor proposals are in the areas of Non-RPC Application Integration, Auditing, and Public Key Support. These directions are described next as well as HP's Security Management direction for DCE (as well as Non-DCE) environments. EXTENSIBILITY TO LEGACY SYSTEMS Extensibility of the data associated with a user or server identity is a key concern for both supporting legacy systems and for adding additional authorization models. HP has submitted DCE-RFC 6 defining a facility for maintaining and verifying arbitrary attributes, such as application or local operating system specific authorization data (e.g., legacy UIDs and passwords), in the DCE Account Registry. This extension will also make possible the implementation of a single logon facility that embraces legacy applications and non-UNIX derived operating systems. DELEGATION The base DCE environment provides mechanisms for clients and servers to perform mutual authentication. In complex environments, however, servers will frequently need to access the services of other servers to perform the request of the client. Delegation or proxy provides a mechanism for chaining services requests securely. HP's DCE-RFC 3 provides a model for chaining identities and enhancements to the authorization model to reflect chained identities. INTER-DOMAIN ACCESS Hierarchical designs provide robustness in the implementation of the security server. This strategy can also be used to reduce the management burden of access across administrative domains. HP's DCE-RFC 7 defines the trust relationships between administrative domains when those domains form a hierarchy in the DCE global name space. STRONGER AUTHENTICATION Stronger authentication protocols protect users from password guessing attacks. HP's DCE-RFC 26 elaborates existing Kerberos protocol features to protect users from network password guessing attacks. These protocol enhancements are coupled with changes to the user registration service so that password guessing attacks can be detected and so that the security system can take corrective action as attacks occur. NON-RPC APPLICATION INTEGRATION Extensions to the DCE security environment have also been proposed by other suppliers. DEC has proposed to broaden the applicability of the DCE security environment to non-RPC applications through the use of the GSSAPI -- a general interface to distributes security services. GSSAPI provides an API for performing mutual authentication and the integrity and confidentiality protection of data without pre-supposing a communication strategy. This addition makes it easier to integrate existing applications that use existing network and communication facilities into DCE by not requiring the application re-engineering with RPC. DEC has further provided DCE-RFC 5 which defines extensions to the GSSAPI to make it work with DCE's authorization data, privilege attribute certificates (PACs). This extension strengthens the appeal of GSSAPI by allowing non-RPC distributed applications to also participate in the DCE authorization model. AUDITING Accountability is essential in many environments. The OSF is considering two competing proposals for the addition of auditing facilities to DCE. The OSF itself has proposed adding an auditing facility in DCE-RFC 25 that would initially audit events in the base security relevant DCE components. IBM has submitted a broader proposal in DCE-RFC 28 and 29 to provide a more general facility appropriate for use in customer applications. The likely adoption of either model will strengthen the DCE and provide a convenient mechanism for key DCE services to integrate with local system auditing facilities in addition to the DCE-wide auditing foreseen in these proposals. PUBLIC KEY SUPPORT A vendor consortium focusing on distributed security called SESAME -- which includes Bull, ICL, and Siemens-Nixdorf -- has proposed a number of extensions in DCE-RFC 19. These extensions would begin the integration of public key support in DCE. Public key (or asymmetric key) protocols are valuable when providing secure offline electronic document interchange and long-term digital signature and notarization services. Inclusion of these protocols in the DCE will provide a common framework for supporting these services and in certain cases will aid cryptographic key distribution. In addition this proposal provides a mechanism for supporting multiple encryption algorithms in DCE. SECURITY MANAGEMENT Simplifying administration is a critical concern for the DCE community in general, and centralized management facilities are a crucial element of HP's strategy for managing DCE and non-DCE environments in particular. Work in this area therefore involves, first, simplifying the administration of existing and planned individual security facilities. For example, OSF's DME project has begun to examine strategies for sharing access control lists (ACLs) among many objects. Roles have also been considered as a means to segment and simplify the administration of these objects. A role model is proposed in DCE-RFC 19. The next step is to develop a common centralized management framework within which individual security facilities can be integrated. In this area HP is investigating the utilization of its OpenView network and system management framework to manage DCE security services as well as DCE-independent security applications and general administration tasks. OSF's DME, which is based heavily on HP's OpenView technology, represents HP's distributed security management long-term direction. OpenView and its DME descendent are ideal technologies for integrating individual security facilities into a common security management framework due to their object-orientation. The characteristics of object manipulation (e.g., inheritance, containment, association) naturally facilitate the integration of security administration attributes. HP is actively prototyping OpenView based security administration tools to demonstrate these concepts. Productization plans will follow. 4.2.4 Security Aspects Not Addressed by DCE Some important security services remain outside the definition of DCE. These service areas are by no means less important than the areas where DCE is currently evolving, but they present difficulties for inclusion in an open software environment, or are being defined and developed in other fora. Examples include non-repudiation facilities, long term digital signature, notary services, and trusted X protocols. Non-repudiation facilities, long-term digital signature, and notary services protect against users denying having sent or received an electronic message. These services are of particular interest to financial services providers that need to protect the integrity of financial transactions against fraud. However, these services are examples of technology that is constrained in use due to licensing issues. Trusted X protocols are required to protect user interfaces based on the X-window system from a threat which they are currently vulnerable to called spoofing. A trusted path for X environments is required to ensure that users have a direct and distinct communication path to the DCE authentication system. It prevents malicious attempts to capture a users password through the use of programs or physical system interfaces designed to trick or spoof users into supplying passwords at fake prompts for authentication secrets (e.g., passwords at logon prompts, PIN numbers at ATM prompts). Trusted X protocols are being pursued by both the X Consortium and the Trusted System Interoperability Group (TSIG) which HP co-founded and also are being examined by the OSF Security SIG. 4.2.5 Role of Local System Support within DCE Domains DCE provides a framework for deploying distributed applications. The success of the environment is not only dependent on the distributed security services of DCE, but also on the integration and support of local system security features. DCE provides a logically centralized repository for system security information, but it does not obviate the need for local security features. Adequate local system security is crucial to the viability of the DCE environment. Moreover, the design of DCE allows the interconnection of machines with varying strength of local security. Vital data repositories and application servers should run on machines that provide strong local operating system and physical security. Besides strong local operating system security features, other local system features which can complement the level of security provided by DCE include smart card integration which can relax the level of trust required in client machines to safely store sensitive information such passwords and encryption keys; system management tools to protect against trojan horses or viruses in local file system nodes; and hardware to increase the performance of data integrity checks and data encryption of DCE applications. Because all of these facilities can complement the level of security in non-DCE environments as well, these facilities are discussed in more detail in section 4.3 which addresses DCE-independent methods to enhance computing environment security. HP's strategies and activities in these areas are also described. 4.2.6 DCE Security Policy Directions The primary goal of DCE is to enable the development and deployment of distributed applications. Generally, the DCE security component avoids implementing policy constraints; it simply makes the definition of policy possible. It is, however, helpful to extend the DCE facilities to simplify the construction of applications applying security policies. Common policy facilities sought after in the commercial environment include separation of duty facilities; shared ACL repository and access validation server; and additional environmental considerations such as access control to objects based on variables such as location of request and time-of-day. 4.3 DCE-Independent Methods to Enhance Computing Environment Security Prior to the proliferation of DCE systems, millions of non-DCE systems, applications, and security schemes will have been deployed as illustrated in the security model graphic found at the introduction of Section 4. In most cases the security of these legacy approaches is much less than desired for future open distributed computing environments. Although stronger security is available in DCE, most existing applications will not be revamped to take direct advantage of DCE's security services. This section discusses some of the DCE-independent methods available from HP or third-party partners to enhance the security of existing environments and without modifying existing applications. They include utilizing enhanced security operating system mechanisms, application support services, system management facilities, trusted hardware components, and networking elements. Other methods are described that can be applied to the task of enhancing the security of new non-DCE applications, as opposed to existing non-DCE applications. They include implementing alternative (i.e., non-DCE) APIs for security services. 4.3.1 Enhanced Security Operating System Mechanisms Enhanced computing environment security can be achieved through operating system level features which may be implemented on DCE or non-DCE nodes. In the case of DCE nodes, this functionality may enforce a local system policy which complements the level of security provided by DCE, as eluded to in section 4.2.5 above. Alternatively, this functionality may be obviated by corresponding functionality available or planned for DCE as stated earlier in section 4.2.6. For non-DCE nodes, however, this type of security represents the traditional data center approach to providing security in a typical standalone host-terminal configuration. Because HP will continue to sell systems into these environments, HP' strategy includes a parallel investment in operating system level facilities for securing the individual stand-alone node regardless of whether or not that node is slated for integration within a DCE environment. HP has already enhanced the security level of its HP-UX operating system with features that are designed to exceed the U.S. Department of Defense National Computer Security Center (NCSC) Orange Book criteria for a C2 rating. These enhancements include an auditing sub-system which improves user accountability by logging all security relevant system events; access control lists (ACLs) which provides increased flexibility in authorizing or restricting file access at the granularity of an individual user; and a protected password database to thwart password guessing attacks. HP has similarly enhanced the level of security in the MPE/ix operating system and is in the process of evaluation with the NCSC targeting a C2 rating. Future HP-UX operating system level enhancements are in the areas of Password Management, Logon Restrictions, and System Administrator Roles. HP plans to deliver the password management and logon restriction functionality in the next major release of its HP-UX operating system. System administrator roles will be offered just as soon as the POSIX standard for least privilege crystallizes. In fact, HP has implemented a super-set of these features in an enhanced security version of HP-UX called HP-UX BLS (B-Level Security). HP-UX BLS addresses the more complex multi-level security needs typical in federal government and defense-related communities which process sensitive information and is in the final (Formal) phase of evaluation by the NCSC targeting a B1 rating. HP's strategy is to leverage its investment in security features already implemented in the HP-UX BLS release stream that are of interest to HP's mainstream commercial accounts -- such as HP-UX BLS password management and logon restrictions -- by migrating these features to HP-UX over time. PASSWORD MANAGEMENT Commercial customers realize that user authentication achieved through a robust password management mechanism is the first line of defense against unauthorized system and data access. Password management mechanisms have been specified by a number of emerging commercial security criteria as a minimum requirement for commercial password management sub-systems (e.g., NIST Minimum Security Functionality Requirements for Multi-User Operating System (MSFR)). They include password generation functions which provide a random pronounceable system generated password option to ensure that all users use effective passwords; password screening which checks user selected passwords against a number of password criteria for complexity and guessability; and password aging mechanisms for setting minimum/maximum password lifetimes. LOGON RESTRICTIONS Logon restrictions or system-level access controls provide commercial customers with the increased flexibility they require to control system access based on attributes such as time-of-day or terminal ID rather than simply User ID. In addition, administrators need the capability to automatically and temporarily disable terminal IDs and/or user accounts based on logon attempts threshold, password or account lifetime expiry, or account inactivity (i.e., dormant accounts). Logon restrictions have also been specified by a number of emerging commercial security criteria as a minimum requirement for commercial system level access controls. SYSTEM ADMINISTRATION ROLES System administration roles enforce the age-old security precept of separation of duty in order to limit the degree of system control entrusted to any individual. Examples of roles include system manager, security administrator, system operator, etc. In a Unix environment this implies eliminating the need for the monolithic and all-powerful super-user privilege and replacing it with more narrowly defined sets of privileges. Super-user privilege is especially dangerous in Unix environments because direct logons are not uniquely identified, and as a result accountability for actions is lost. A least privilege model, which supports the principle that each subject should be given no more privilege than absolutely required to perform its intended function, represents the preferred approach to implementing system roles effectively. A least privilege model for open systems is not practical today due to the immaturity of the emerging standard for privilege definition. Nevertheless, secure administrator interfaces (e.g., menus, restricted shells) which limit administrators to predefined tasks can be utilized today. However, this approach does not provide the same level of assurance as a least privilege model. 4.3.2 Application Support Services Application support services can be implemented above the operating system level to enhance the security of non-DCE domains which host distributed applications. Non-DCE distributed-applications tend to use conventional networking services provided by communication software libraries (e.g., TCP/IP, SNA, SPX/IPX, or X.400 messaging). Enhancing the default security of these services is one way of bringing applications into a more secure distributed environment without modifying the applications which use them. For example, it is possible to force TCP/IP connections to be encrypted providing near end-to-end privacy. This approach may be attempted with any runtime libraries that support existing applications. HP's strategy is to follow the recommendations of the Internet Engineering Task Force (IETF) for enhancing the security capabilities of both TCP/IP and the Simple Network Management Protocol (SNMP II) which is built upon TCP/IP. Legacy applications may use a variety of other application support services. They may be based on vendor supplied de facto standards or custom built ad hoc solutions. Also, they may be operating system or environment based (e.g., database security features like Views, Novell network logon). On an individual basis, interfaces may be designed to integrate these methods into a more standard security facility (e.g., X.509) or even into remote DCE security services. In some cases vendors will be evolving these interfaces from their proprietary approach to a more standard security methodology. For example, leading relational database vendors are delivering secure database engines which utilize the security facilities of selected standards-based secure operating systems. Both Oracle and Informix have selected HP's trusted (B-Level) secure Unix-based operating system, HP-UX BLS, as the reference platform to base National Computer Security Center evaluations of their B1-Level secure database offerings. 4.3.3 System Management Facilities Another approach to improving general computing environment security is to implement system management facilities which either provide a security assessment function or integrated system management facilities which encompass security audit and control as well most general system administration tasks. SECURITY ASSESSMENT TOOLS These tools can offer consolidated network security assessment, risk analysis, security policy or baseline exception-condition reporting, monitoring, and automatic correction facilities thereby dramatically reducing the time and expertise required to maintain and improve security in distributed environments. These security assessment software products generally focus heavily on file system attributes which if not set securely can leave the system vulnerable to a number of threats including unauthorized use, viruses, and trojan horse attacks. Security assessment software can also include error log analysis, configuration guidelines, password administration, process inventory, and networking profiles. This software can be run on demand or continuously depending on performance and administration overhead sensitivity. HP's strategy is to ensure that the leading independent software vendor products that perform these functions are available on HP hardware platforms. Examples of such products which HP-UX currently supports include the Security Toolkit from Raxco Systems and SecureMax from Demax Software. INTEGRATED SYSTEM MANAGEMENT TOOLS Some system management add-on products are much more ambitious with regard to the scope of security and system management facilities they offer than the security assessment software products just described. They include IBM's Resource Access Control Facility (RACF) and Computer Associates Top Secret and ACF2 for data center environments and CA-Unicenter which has been ported to the HP-UX platform. For example, CA-Unicenter for HP-UX supplants most of the security controls built into HP-UX such as the logon sub-system, file system access controls, and auditing sub-system as well as most other general system management facilities such as performance, storage, production, as well as security audit and control management. Computer Associates is in the process of evolving this management architecture to support distributed, multi-vendor environments. HP's strategy is to offer this approach to customers that wish to down-size from larger IBM mainframe systems while retaining familiar system management concepts and interfaces. For customers willing to re-engineer their global computing architecture, HP provides the flexibility and scalability of DCE. The graphic below illustrates how the traditional system security model for HP-UX (right-middle portion of graphic) compares with the mainframe, data center approach as exemplified by the CA-Unicenter product for HP-UX (far-right portion of graphic). Note, the traditional system security model for HP-UX consists of built-in operating system level security features (as described in Section 4.3.1), a system administration environment, and add-on security assessment tools. This contrasts with the CA-Unicenter architecture which spans all three security layers depicted in the model. 4.3.4 Networking Elements While the previous sections focused on efforts to improve security via on-host mechanisms, this section addresses off-host approaches based on the communication components (e.g., bridges, multiplexors, modems, routers) that comprise the network. Enhancing the security of these elements or adding link security devices (e.g., link encryption devices) can usually be accomplished transparently with respect to existing applications. Furthermore, these methods generally can continue to be used even with the introduction of higher level security methods such as end-to-end encryption (ETE). If all applications were using ETE encryption link encryption of course would be redundant. However, in cases where existing applications and systems cannot be enhanced with ETE or near-ETE encryption, link encryption would certainly improve confidentiality of these applications. HP supports third-party link encryption devices which provide this level of service. It is generally recognized, however, that ETE encryption is clearly the best solution whenever achievable. There are many other security enhancements that can be added at the link level besides encryption. For example, bridge filter tables can be used to segregate network traffic by source or destination address. Routers can filter traffic based on message type, and higher level addressing such as the Internet or Novell network address protocol (XPI). Once again these methods generally do not interfere with the introduction of security methods such as ETE encryption. HP is adding these type of security services as well as link encryption capabilities to its bridge and router product lines. In addition, modems are available from third-parties with dial-back, password, or encryption capabilities, to strengthen remote sign-on user authentication. A significant disadvantage of using network elements to enhance the security of a distributed application lies in the area of administration. The simple task of adding a new PC or workstation to a work group illustrates this point. The administrator must perform all of the normal account setup activities on relevant servers and clients. Often this has been automated because of the repetitive nature of the task. However, if the bridge filtering technique had been deployed as described above, then the administrator must include the ethernet address of the new PC or workstation in the bridge filter table or else the new node will not be able to communicate with the servers. Thus, required knowledge of ethernet addresses and network topologies complicate otherwise routine account set up tasks. HP's DCE provides a centralized management framework for distributed security which may obviate the need for network security elements. 4.3.5 Trusted Hardware Components Security of both DCE and non-DCE systems can be enhanced by means of trusted hardware components. Encryption hardware and smart cards are two examples of this type of component. HP is actively developing encryption hardware which is integrated with and complementary to its smart card support plans. Encryption hardware provides a highly trusted facility in which keys can be stored and in which highly optimized encryption and decryption services can be performed. The software and/or hardware that carry out these services can be trusted to protect against unauthorized modification or trojan horse attacks. This level of trusted key storage and performance is required to successfully support digital signature, message authentication, and data encryption activities in untrusted systems. Smart cards provide a low cost but trusted facility that can be used to strengthen weak parts of the authentication process such as user selected passwords. They can also be used to assist in the digital signature process. Their tamper resistant features together with their nature as personal device make them a socially acceptable security enhancement for the mobile user community. While today's smart cards tend to be single purpose cards there is a good deal of interest in developments that make use of multi-purpose smart cards which could support system-usage accounting and chargeback controls, software license controls, as well as security access controls. 4.3.6 Alternative APIs for Security Services The previous sections focusing on non-DCE environment security emphasized methods to avoid modification of existing applications. This section examines non-DCE facilities that are useful to application developers who choose to include certain security features in their applications. First, there are APIs available for accessing general security services (e.g., GSS, CCS, TSS). These APIs are available in packages from some vendors today. HP is driving for the emergence of a standard API and will implement this API in its product offerings. Second, there are some product specific APIs available for accessing specific security features. For example, widely adopted products can establish defacto standard APIs for particular security services (e.g., Kerberos authentication services, RSA encryption services). The range of products available in this area is growing quickly. They are often attractive to organizations that have identified one or two key security threats. However, an administration and interoperability problem becomes apparent as more and more threats are identified and more security products are integrated. Since there is no standardization effort in this area, interoperability of these various security solutions is very much a custom process. HP recommends that before following this path, it is wise to select an umbrella security architecture standard (e.g., X.509, DCE, RACF) into which independent solutions can be integrated. 4.3.7 Alternative Security Architecture Standards The Directory based authentication framework (X.509, ISO9594-8) is an example of a standard that can be used to support an enterprise security architecture. Since the directory holds information that is needed for communication protocols and is accessed prior to communicating, it is a natural place to store, distribute, and maintain authentication information. X.509 describes some specific attributes necessary to support simple and strong authentication, however, this is an extensible facility and other security attributes can be defined. The most significant attribute specified in X.509 is the user's certificate -- a collection of information about a user that is produced by a trusted certification authority. The certificate is important in that it provides an internationally standardized means to disclose a user's public key. As mentioned previously, support for public key cryptography is fundamental to most modern authentication schemes. Both the certificate content and its use are extensible to support a specific enterprise security policy without impacting open systems interoperability. Furthermore, the certification authority necessary to create certificates requires adaption to the enterprises specific corporate structure. The viability of using X.509 to support enterprise security architectures depends on the growth and availability of Directory products. Although X.509 can be considered as an umbrella enterprise security architecture, HP's position is that the DCE architecture is a more comprehensive solution for integrating alternative security environments including X.509. 4.4 Network Planning Planning for security enhancements is an important first step and can be carried out even when budgets are tight and ideal solutions have not yet matured. The planning process should begin with a projection of organizational requirements for IT. In the 90's these requirements generally reflect aggressive distributed computing services that offer competitive performance and flexibility. Security may or may not be included in an organization's outlook for IT growth. HP's position is that security should be included in IT planning and offers consulting services to assist with this activity. If DCE is chosen as the future environment for an enterprise then the DCE security framework can be used for network planning of security services. Even if the entire enterprise does not uniformly deploy DCE, the DCE security framework can be used as the overarching security architecture for the non-DCE components. Network planning would then include identification of interfaces between the non-DCE systems and the DCE security services. There will be environments where DCE services will not be accessible or where a non-DCE security framework has been chosen as the overarching architecture (e.g., X.509). Network planning in these cases will involve designing of the interfaces required to integrate various security solutions into the chosen architecture. Network planning for security should include an assessment of emerging security related technologies and their impact on improving distributed computing. For example, smart cards can provide strengthened authentication and support for digital signature even in very untrusted systems like PCs. In many commercial business sectors the cost of smart card integration is being defrayed by the savings from reduction in fraud and misuse. Once again, planning is important in understanding how smart cards would be introduced, used, and administered in any given application environment. Network planning also must consider solutions and activities which are not technology driven such as security policy development; user awareness, education, and training; physical security options; and network configuration techniques. For example, traditional network configuration techniques such as firewalling can be used to protect a trusted local area network while preserving a level of remote communication. Within the security perimeter of a LAN, users may communicate freely. But, all messages sent to or from users outside the network must pass through a firewall or gateway computer, that checks, routes, and labels information passing through it. In sum, HP can bring to bare the power of consulting and technological solutions to address customer security needs. 5 Application of HP's Security Strategy: Case Example The previous sections of this white paper describe HP's security vision and implementation strategy. This section offers an example of how HP's security vision and model can be used to meet a specific customer requirement for a consolidated logon process. CONSOLIDATED LOGON PROCESS A consolidated logon process provides user authentication at a network entry point. Users engage in a single logon dialog with the network security service. Once users are authenticated, they may access a variety of applications and servers without additional logon dialog. The figure illustrates an approach to consolidated logon which utilizes proposed extensions to the DCE user registry facility. It provides a mechanism to incorporate existing applications into the DCE environment. This approach assumes that the network entry point system supports DCE. As shown in the figure, the various proof mechanisms for all networked systems are collected into a Security Registry. The Security Registry contains all the security relevant attributes of the various users. These attributes may include information such as account identifiers (user ids) and passwords for legacy systems and applications. The Security Registry is based on enhancements to DCE currently planned for DCE 1.1 and described in OSF DCE SIG RFC 6.0 - A Generic Interface for Extended Registry Attributes. The current DCE 1.0 repository stores the network privilege attributes used by DCE as well as local account attributes usable by UNIX operating systems. The enhancements planned for DCE 1.1 provide a mechanism for storing user and group attributes for arbitrary operating systems. These attributes may be used to implement a consolidated logon process. Network access is controlled by a specialized logon client which is a DCE application. This logon client may run on any system which supports DCE including PCs running PC-DCE from Gradient Technologies. Users access the logon client either directly via the workstation display or attached terminal or indirectly from a non-DCE client via some trusted protocol outside the scope of DCE. The logon client processes the security attributes received from the Security Registry. These attributes include standard DCE security attributes as well as user and group attributes such as user ids and passwords for legacy operating environments. The logon client passes these security attributes to various application and client processes via operating system specific mechanisms. Legacy applications can be supported in the consolidated logon environment in a number of ways. A variety of possibilities are examined below in the order of increasing modification to the application. In all cases there is no need to change the application's security model. 1. Local applications. These applications run on the same system as the DCE logon client. Security attributes are passed to them via standard operating system mechanisms. No changes are made to the legacy application. 2. Existing Remote Legacy Applications. These are applications which are already distributed and have their own protocol for transmitting authorization data. For these applications, user account/password attributes are passed to the applications via some non-RPC network interface. The attributes are used to provide operating system or application specific authentication and authorization, possibly using some scripting mechanism. For example, HLLAPI may be used to pass logon information to an existing IBM application. No changes need to be made to these applications. 3. Encapsulated Legacy Applications. These are legacy applications which run on a system which supports DCE. These applications are encapsulated in a DCE Wrapper which provides remote access to the application. Extended security attributes for these applications are passed in a standard DCE PAC (Privilege Attribute Certificate). The wrapper function processes the remote request and sets the local O.S. environment to reflect the legacy attributes. The legacy application is then invoked by the DCE wrapper in the normal local manner. No changes are made to the legacy application. 4. Client/Server Legacy Applications. These are existing client/server applications which use some non- RPC communications mechanism such as LU 6.2 or Berkeley Sockets. The GSS API described in OSF DCE SIG RFC 5.0 (if available on the legacy platform) may be used to add security features to these applications. The security features offered are analogous to those which DCE offers to RPC-based applications. The legacy application retains its existing communications model but adds the use of GSSAPI to achieve secure transmission of authorization data and for the integrity or confidentiality protection of the communication. 5. Re-engineered DCE Applications. These applications use standard DCE mechanisms for communication. Remote interfaces are designed to use RPC. Extended security attributes for these applications are passed in a standard DCE PAC (Privilege Attribute Certificate).